fix(dell): set Secure Boot via the SecureBoot BIOS attribute - #471

iDRAC allows one pending BIOS config job at a time. Any write to
Bios/Settings, or to a resource that mirrors a BIOS attribute such as
the SecureBoot resource, seals that job, and every further write is
rejected with SYS011 until the job is deleted or has run. Two
BIOS-affecting calls in one boot cycle therefore fail on the second,
although both would apply together at the next reset.

SetBiosConfiguration now reads the pending attributes before writing:

- Nothing pending: a plain write, as before.
- Something pending: delete the live job (only if it has not started
  applying), merge the requested attributes over the staged ones and
  write once. The merge carries attributes an earlier caller staged,
  because iDRAC keeps a single job and deleting it discards what it
  staged. If the merged write fails, the attributes the deleted job
  held are staged again and the error says whether that worked. The
  deletion is logged.
- Every requested attribute already at the requested value, staged or,
  where nothing is staged for it, applied, with a live job carrying the
  staged ones: nothing is done, so repeating a call is idempotent.

A SYS011 the read could not foresee is returned to the caller, with a
note when no job could be found to delete.
The sequence is not safe against another client writing BIOS settings
on the same BMC at the same time.

A job is recognized by Oem.Dell.JobType or by its "ConfigBIOS:" name, as
not every iDRAC generation returns an Oem block in the JobService
collection. It is deleted only in a state in which it has not started,
and only if Dell's own job resource, the one the firmware code already
reads, shows no ActualRunningStartTime: that resource reports it on
every generation. A pending job shows "Scheduled" or "Starting"
depending on the generation; gofish's JobState set has neither. Unknown
states are refused rather than assumed safe.

Tested against a PowerEdge R760xd2 (iDRAC 7.30.10.50) and a PowerEdge
R6715 (iDRAC 1.20.80.51).

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Signed-off-by: Mickaël Canévet <mickael.canevet@proton.ch>

Dell's SetSecureBoot delegated to the shared Redfish implementation, which PATCHes the standard
ComputerSystem SecureBoot resource's SecureBootEnable property. That PATCH unconditionally
creates iDRAC's one exclusive BIOS Configuration Job, so it is order-dependent: run before
another Bios/Settings write in the same boot cycle, it makes that later write fail with
SYS011; the reverse order merges cleanly because no job exists yet.

PATCH the SecureBoot BIOS Setup attribute via SetBiosConfiguration instead, so SetSecureBoot
goes through the same Bios/Settings path as every other Dell BIOS-backed setter. A write made
before or after it, in the same boot cycle, is then merged into the same pending job instead of
being rejected.

Behaviour is otherwise unchanged: the write is staged into Bios/Settings and takes effect on
the next POST.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Signed-off-by: Mickaël Canévet <mickael.canevet@proton.ch>